Result of nixpkgs-review pr 301397 run on x86_64-linux 1

Can we use 'just' to install ? there are some '/usr' path need patch
https://github.com/Rolv-Apneseth/rofi-games/blob/e4dca5222133c7c8956c42cc58b6dd27d5e8656c/justfile#L17

Nixpkgs has a custom way of installing rofi plugins:

if you don't have home-manager, then you can change

environment.systemPackages = [
  ...
  pkgs.rofi
];

to

environment.systemPackages = [
  (pkgs.rofi.override { plugins = [ pkgs.rofi-games ]; })
];

It's a bit easier if you have home-manager:
Add this to your home manager config:

programs.rofi = {
  enable = true;
  plugins = [ pkgs.rofi-games ];
};

You will also need to select the theme when calling rofi

Obviously pkgs.rofi-games doesn't yet exist outside of this PR, so you might need to use overlays, or any other method.
Here's an example:
first copy the file from this PR to your config directory and set plugins accordingly:

plugins = [ (pkgs.callPackage ./rofi-games.nix {}) ];

I haven't tested what I've written here, but should be correct.

I don't quite understand how it remains binary compatible with rofi. For example, rofi and rofi-wayland are currently incompatible, so all libraries written in C need to be built again with rofi-wayland instead of rofi as a dependency. But this package does not introduce any additional dependencies. The rofi-mode it relies on also doesn't seem to have anything to do with a build of rofi.

I don't quite understand how it remains binary compatible with rofi. For example, rofi and rofi-wayland are currently incompatible, so all libraries written in C need to be built again with rofi-wayland instead of rofi as a dependency. But this package does not introduce any additional dependencies. The rofi-mode it relies on also doesn't seem to have anything to do with a build of rofi.

Apparently this line was supposed to do the version detection of rofi, conditionally setting the rofi_next flag.
https://github.com/Rolv-Apneseth/rofi-games/blob/e4dca5222133c7c8956c42cc58b6dd27d5e8656c/justfile#L30
however, I'm doing a custom build and install, so it doesn't trigger.

Should I just introduce a .override-able flag or should I expect the rofi to be passed with .override and use the detection in the justfile?

Got a solution.

  # Get rofi version from justfile to ensure abi compatibility
  preBuild = ''
    export RUSTFLAGS+=" $(${lib.getExe just} --evaluate RUSTFLAGS)"
  '';

  nativeBuildInputs = [
    pkg-config
    rofi
  ];

Isn't pretty, though... You can also use just to control the build process.

  # Get rofi version from justfile to ensure abi compatibility
  preBuild = ''
    export RUSTFLAGS+="$(${lib.getExe just} --evaluate RUSTFLAGS)"
  '';

  nativeBuildInputs = [
    pkg-config
    rofi
  ];

Isn't pretty, though... You can also use just to control the build process.

Thanks, I'll push a commit shortly which just uses just and patches the justfile. Good to know you can do --evaluate.

just should have some command line options to edit or override those args. Will look into it tomorrow.

just should have some command line options to edit or override those args. Will look into it tomorrow.

The build phase only calls just with the justFlags as the inputs.

However, justFlags is used in all other phases too, which would mean that the install phase would do just build install, which is weird

Hey, not sure if anything needs to be done on this end, but just wanted to give a heads up that I have since pushed some changes to rofi-games. Probably the only one that matters for this PR is support for a user config file at $XDG_CONFIG_HOME/rofi-games/config.toml.

Hey, not sure if anything needs to be done on this end, but just wanted to give a heads up that I have since pushed some changes to rofi-games. Probably the only one that matters for this PR is support for a user config file at $XDG_CONFIG_HOME/rofi-games/config.toml.

Thanks for the heads up!